昨天寫完那篇，我發現可能會讓人誤會，以為這系列在講的是我怎麼跟一個聊天視窗小心翼翼對話。不是。老實說我背後跑的東西大很多。

這半年我花了不少時間，不是在跟 AI 要答案，是在幫自己的工作弄一套系統。判斷寫成文件，不放在我腦子裡，這樣哪天換一個比較弱的模型接手，照著文件走，產出不會掉下去。複雜一點的事情交給幾個分工的角色去跑，各自顧各自的，我不用每次都重講一次背景。有一部分工作是排程自動跑的，跟我有沒有坐在電腦前面沒關係。東西要發出去之前一定要過幾層檢查，AI 從頭到尾都沒有按下發布這個按鈕的權限，那個權限只在我手上。

然後這系列真正想做的事情，是把同一套邏輯搬去做工程這件事本身。不是拿去發文章而已，是需求定義、設計、實作、測試、上線，這整條開發線，我自己一個人用這套系統跑完一遍。以前這是一個團隊分工才擠得出來的事。

老實說我一開始沒什麼把握，覺得少了團隊互相盯，出包的機率只會更高，一個人少了別人幫你補位，漏洞應該更多才對。

後來發現問題不是一個人夠不夠，是你有沒有把原本團隊裡每個角色在做的檢查，重新蓋回自己的流程裡。以前需求有 PM 把關，設計有人 review，code 有人 code review，上線前有人測試，這些角色沒有消失，是我自己一個人要輪流戴上每一頂帽子，還要記得脫下上一頂才能戴下一頂，不能混在一起做，講起來自己都覺得有點好笑 XD。

接下來這系列，我會把用法跟實作過程整個攤開來講，不會只講原則。之後會寫到：需求定義那段怎麼變成整條線裡最花時間的地方，跟大家想的不一樣；一個人跑的時候要怎麼防止自己騙自己，因為原本測試那關的人也是我自己；同一件事讓 AI 連錯兩次，我會怎麼換掉整套做法而不是求它重試；還有到現在為止，哪些決定我還是堅持自己下，沒打算交出去。這些都是我自己每天真的在做的事，做錯的地方也會照樣寫出來。

下面講需求定義那段，我自己覺得這段最反直覺。